Metodologías de desarrollo de software. ¿Cuál es el camino? (página 2)
Beneficios que aporta RUP
- Permite desarrollar aplicaciones sacando el máximo
provecho de las nuevas
tecnologías, mejorando la calidad, le
rendimiento, la reutilización, la seguridad y
el mantenimiento del software
mediante una gestión sistemática de los
riesgos.
[ANO05, 1]. - Permite la producción de software que cumpla con las
necesidades de los usuarios, a través de la
especificación de los requisitos, con una agenda y
costo
predecible. [ANO05,1]. - Enriquece la productividad
en equipo y proporciona prácticas óptimas de
software a todos sus miembros. [ANO05, 2]. - Permite llevar a cabo el proceso de
desarrollo
práctico, brindando amplias guías, plantillas y
ejemplos para todas las actividades críticas. [ANO05,
2]. - Proporciona guías explicitas para áreas tales
como modelado de negocios,
arquitectura
Web, pruebas y
calidad. También se proporciona guías para
desarrollar en plataformas IBM WebSphere y Microsoft
Web Solution para acelerar el desarrollo de los proyectos.
[ANO05, 2]. - Se integra estrechamente con herramientas
Rational, permitiendo a los equipos de desarrollo aprovechar
todas las ventajas de las características de los
productos
Rational, el Lenguaje
de Modelado Unificado (UML) y otras
prácticas óptimas de la industria.
[ANO05, 2]. - Unifica todo el equipo de desarrollo de software y mejora
la
comunicación al brindar a cada miembro del mismo una
base de conocimientos, un lenguaje de
modelado y un punto de vista de cómo desarrollar
software. [ANO05, 2]. - Optimiza la productividad de cada miembro del equipo al
poner al alcance la experiencia derivada de miles de proyectos
y muchos líderes de la industria. - No solo garantiza que los proyectos abordados serán
ejecutados íntegramente sino que además evita
desviaciones importantes respecto a los plazos. [ANO05,
3]. - Permite una definición acertada del sistema en un
inicio para hacer innecesarias las reconstrucciones parciales
posteriores. [ANO05, 3].
Metodologías ágiles.
XP
La Programación Extrema surge ideada por Kent
Beck, como proceso de creación de software diferente al
convencional. En palabras de Beck: "XP es una metodología ligera, eficiente, con bajo
riesgo,
flexible, predecible y divertida para desarrollar software".
Objetivos de XP:
Los objetivos de
XP son muy simples: la satisfacción del cliente.
Esta metodología trata de dar al cliente el
software que él necesita y cuando lo necesita. Por tanto,
debemos responder muy rápido a las necesidades del
cliente, incluso cuando los cambios sean al final de ciclo de la
programación.
El segundo objetivo es
potenciar al máximo el trabajo en
grupo. Tanto los jefes de proyecto, los
clientes y
desarrolladores, son parte del equipo y están involucrados
en el desarrollo del software.
Bases de XP
La programación extrema se basa en la simplicidad, la
comunicación y el reciclado continuo de
código,
para algunos no es más que aplicar una pura lógica.
Lo que buscan en definitiva es la reducción de costes.
Valores XP
Una de las cosas que a los programadores nos tiene que quedar
muy claro es que en el ciclo de vida
del desarrollo de un proyecto software los cambios van a
aparecer, cambiarán los requisitos, las reglas de negocio,
el personal, la
tecnología, todo va a cambiar. Por tanto el
problema no es el cambio en si,
ya que este va a suceder sino la incapacidad de enfrentarnos a
estos cambios.
Como en otra cualquier actividad humana necesitamos valores para
desarrollar nuestro trabajo y
conseguir los planteamientos iniciales.
Estos cuatro valores son:
- Comunicación
- Sencillez
- Retroalimentación
- Valentía
Variables XP
XP define cuatro variables para
proyectos de software:
- Coste
- Tiempo
- Calidad
- Ámbito.
Actividades básicas XP
Ahora que tenemos nuestros cuatro valores estamos preparados
para construir una disciplina de
desarrollo de software. ¿Qué tareas debemos de
llevar a cabo para desarrollar un buen software?
Codificar
Es la única actividad de la que no podremos prescindir.
Sin código fuente no hay programa, aunque
hay gente que cuenta que existe software en producción del
que se perdió el código fuente. Por tanto
necesitamos codificar y plasmar nuestras ideas a través
del código. En una programación en XP en pareja el
código expresa tu interpretación del problema, así
podemos utilizar el código para comunicar, para hacer
mías tus ideas, y por tanto para aprender y mejorar.
Hacer pruebas
Las características del software que no pueden ser
demostradas mediante pruebas simplemente no existen. Las pruebas
me dan la oportunidad de saber si lo que implementé es lo
que en realidad yo pensaba que había implementado. Las
pruebas nos indican que nuestro trabajo funciona, cuando no
podemos pensar en ninguna prueba que pudiese originar un fallo en
nuestro sistema entonces has acabado por completo.
No debemos de escribir tan solo una prueba ver que funciona y
salir corriendo, debemos de pensar en todas las posibles pruebas
para nuestro código, con el tiempo
llegarás a conclusiones sobre las pruebas y podrás
pensar que si dos de tus pruebas ya funcionan la tercera prueba
no será necesaria escribirla, sin caer en demasiada
confianza.
Programar y probar es más rápido que sólo
programar. Puedes ganar media hora de productividad sin hacer
pruebas, pero perderás mucho tiempo en la
depuración. Tendrás menos errores, tendrás
que volver menos veces sobre el código, te costará
menos localizar los errores, perderás menos tiempo
escuchado como tus clientes te dicen que no funciona.
Las pruebas deben de ser sensatas y valientes. No podemos
hacer pruebecillas que no testen a fondo el sistema, esos
agujeros que vamos dejando nos esperan para cuando pasemos de
nuevo por allí y volveremos a caer dentro.
Escuchar
Los programadores no lo conocemos todo, y sobre todo muchas
cosas que las personas de negocios piensan que son interesantes.
Si ellos pudieran programarse su propio software ¿ para
que nos querrían ?.
Si vamos a hacer pruebas tenemos que preguntar si lo obtenido
es lo deseado, y tenemos que preguntar a quien necesita la
información. Tenemos que escuchar a
nuestros clientes cuales son los problemas de
su negocio, debemos de tener una escucha activa explicando lo que
es fácil y difícil de obtener, y la
realimentación entre ambos nos ayudan a todos a entender
los problemas.
Diseñar
El diseño
crea una estructura que
organiza la lógica del sistema, un buen diseño
permite que el sistema crezca con cambios en un solo lugar. Los
diseños deben de ser sencillos, si alguna parte del
sistema es de desarrollo complejo, divídela en varias. Si
hay fallos en el diseño o malos diseños, estos
deben de ser corregidos cuanto antes.
Tenemos que codificar porque sin código no hay programas,
tenemos que hacer pruebas por que sin pruebas no sabemos si hemos
acabado de codificar, tenemos que escuchar, porque si no
escuchamos no sabemos que codificar ni probar, y tenemos que
diseñar para poder
codificar, probar y escuchar indefinidamente.
Prácticas Básicas de XP
El juego de la
planificación.
Hay una comunicación frecuente el cliente y los
programadores. El equipo técnico realiza una
estimación del esfuerzo requerido para la
implementación de las historias de usuario y los clientes
deciden sobre el ámbito y tiempo de las entregas y de cada
iteración.
Pequeñas versiones.
Cada versión debe de ser tan pequeña como fuera
posible, conteniendo los requisitos de negocios más
importantes, las versiones tiene que tener sentido como un todo,
me explico no puedes implementar media característica y
lanzar la versión.
Es mucho mejor planificar para 1 mes o 2 que para seis meses y
un año, las compañías que entregan software
muy voluminoso no son capaces de hacerlo con mucha
frecuencia.
Metáfora.
Una metáfora es una historia que todo el mundo
puede contar a cerca de cómo funciona el sistema. Algunas
veces podremos encontrar metáforas sencillas "Programa de
gestión de compras, ventas, con
gestión de cartera y almacén".
Las metáforas ayudan a cualquier persona a
entender el objeto del programa.
Diseño sencillo.
El diseño adecuado par el software es aquel que:
1. Funciona con todas las pruebas.
2. No tiene lógica duplicada.
3. Manifiesta cada intención importante para los
programadores
4. Tiene el menor número de clases y métodos.
Haz el diseño lo más simple posible borra todo
lo que puedas sin violar las reglas 1,2 y 3. Contrariamente a lo
que se pensaba el "Implementa para hoy, diseña para
mañana", no es del todo correcto si piensas que el futuro
es incierto.
Hacer pruebas.
No debe existir ninguna característica en el programa
que no haya sido probada, los programadores escriben pruebas para
chequear el correcto funcionamiento del programa, los clientes
realizan pruebas funcionales. El resultado un programa mas
seguro que
conforme pasa el tiempo es capaz de aceptar nuevos cambios.
Recodificación.
Cuando implementamos nuevas características en nuestros
programas nos planteamos la manera de hacerlo lo mas simple
posible, después de implementar esta
característica, nos preguntamos como hacer el programa mas
simple sin perder funcionalidad, este proceso se le denomina
recodificar o refactorizar (refactoring). Esto a veces nos puede
llevar a hacer mas trabajo del necesario, pero a la vez estaremos
preparando nuestro sistema para que en un futuro acepte nuevos
cambios y pueda albergar nuevas características. No
debemos de recodificar ante especulaciones si no solo
cuándo el sistema te lo pida.
Programación por parejas.
Todo el código de producción lo escriben dos
personas frente al ordenador, con un sólo ratón y
un sólo teclado. Cada
miembro de la pareja juega su papel: uno codifica en el ordenador
y piensa la mejor manera de hacerlo, el otro piensa más
estratégicamente, ¿Va a funcionar?, ¿Puede
haber pruebas donde no funcione?, ¿Hay forma de
simplificar el sistema global para que el problema
desaparezca?
El emparejamiento es dinámico, puedo estar emparejado
por la mañana con una persona y por la tarde con otra, si
tienes un trabajo sobre un área que no conoces muy bien
puedes emparejarte con otra persona que si conozca ese
área. Cualquier miembro del equipo se puede emparejar con
cualquiera.
Propiedad colectiva.
Cualquiera que crea que puede aportar valor al
código en cualquier parcela puede hacerlo, ningún
miembro del equipo es propietario del código. Si alguien
quiere hacer cambios en el código puede hacerlo. Si
hacemos el código propietario, y necesitamos de su autor
para que lo cambie entonces estaremos alejándonos cada vez
mas de la comprensión del problema, si necesitamos un
cambio sobre una parte del código lo hacemos y punto. XP
propone un propiedad
colectiva sobre el código nadie conoce cada parte igual de
bien pero todos conoce algo sobre cada parte, esto nos
preparará para la sustitución no traumática
de cada miembro del equipo.
Integración continúa.
El código se debe integrar como mínimo una vez
al día, y realizar las pruebas sobre la totalidad del
sistema. Una pareja de programadores se encargara de integrar
todo el código en una maquina y realizar todas las pruebas
hasta que estas funcionen al 100%.
40 Horas semanales.
Si queremos estar frescos y motivados cada mañana y
cansado y satisfecho cada noche. El viernes quiero estar cansado
y satisfecho para sentir que tengo dos días para pensar en
algo distinto y volver el lunes lleno de pasión e ideas.
Esto requiere que trabajemos 40 horas a la semana, mucha gente no
puede estar más de 35 horas concentrados a la semana,
otros pueden llegar hasta 45 pero ninguno puede llegar a 60 horas
durante varias semanas y aun seguir fresco, creativo y confiado.
Las horas extras son síntoma de serios problemas en el
proyecto, la regla de XP dice nunca 2 semanas seguidas realizando
horas extras.
Cliente In-situ.
Un cliente real debe sentarse con el equipo de programadores,
estar disponible para responder a sus preguntas, resolver
discusiones y fijar las prioridades. Lo difícil es que el
cliente nos ceda una persona que conozca el negocio para que se
integre en el equipo normalmente estos elementos son muy
valiosos, pero debemos de hacerles ver que será mejor para
su negocio tener un software pronto en funcionamiento, y esto no
implica que el cliente no pueda realizar cualquier otro
trabajo.
Estándares de codificación.
Si los programadores van a estar tocando partes distintas del
sistema, intercambiando compañeros, haciendo refactoring,
debemos de establecer un estándar de codificación
aceptado e implantado por todo el equipo.
Características esenciales de XP
- Roles.
- Programador: Produce el código del
sistema. - Cliente: Escribe las HU y las pruebas
funcionales para validar su implementación, así
como asigna la prioridad de la HU y decide cuál se
implementara en cada iteración. - Encargado de pruebas: Ayuda al cliente a
escribir las pruebas funcionales, ejecuta las pruebas y difunde
resultados además es responsable de las herramientas de
soporte para prueba. - Rastreador (Tracker):también conocido como
"Metric Man", observa sin molestar y mantiene los datos
históricos. - Consultor: Es un miembro externo del equipo con
conocimiento
especifico de algún tema necesario para el proyecto.
Guía al equipo para resolver un problema
específico. - Gestor (Big Boss): Es el vínculo entre
clientes y programadores, ayuda a que el equipo trabaje
efectivamente creando las condiciones adecuadas. Su labor
esencial es de coordinación.
- Artefactos esenciales.
- Historias de Usuario.
- Tareas de Ingeniería.
- Pruebas de Aceptación.
- Procesos.
- Ciclo de desarrollo.
- Ciclo de vida(Fases)
- Exploración
- Planificación.
- Iteraciones.
- Producción.
- Mantenimiento.
- Muerte Proyecto.
- Prácticas.
3P [ECH08].
Paradigma 3P es una metodología de desarrollo
de software nacida al calor de
la experiencia acumulada del grupo de
investigación y desarrollo Atis debido
a la insuficiente capacidad de respuesta a los clientes
utilizando las metodologías tradicionales.Principios que sustentan el
modelo- Los individuos y sus interacciones son más
importantes que los procesos
y las herramientas: El PERSONAL. - La comunicación con el cliente evita
construir una elegante solución para un problema
equivocado: El PROBLEMA. - El software que funciona es más importante
que la documentación exhaustiva. El
PROCESO.
Valores 3P
- Comunicación: Sin comunicación todo
proyecto estaría destinado a fracasar , comunicar no
es escribir o hablar muchas palabras sino utilizar solo las
palabras necesarias para trasmitir una idea. - Sencillez: Nadie es mejor o peor que los
demás miembros del grupo de desarrollo , todos
tenemos fortalezas y debilidades, conocerlas hará
que nuestras relaciones con los miembros del grupo sean
mejores en el orden profesional y personal. - Retroalimentación: Saber cuándo se
debe rehacer algo que no funciona, equivocarse es de
humanos, encarar nuevamente la tarea con emprendimiento y
optimismo. - Emprendimiento: estar dispuesto siempre a
acometer las tareas más complejas, encararla con
esmero y con alegría hará que crezca nuestro
prestigio entre los demás miembros, la
convicción y el deseo del triunfo debe
prevalecer. - Optimismo: Ser realista pero tener siempre el
pensamiento orientado hacia el éxito.
Actividades básicas
- Codificar.
- Probar.
- Comunicar
- Idear
- Escuchar.
- Diseñar.
Roles del proyecto
- Jefe del Proyecto
- Cliente
- Consultor
- Analista-Programador
- Programador
- Diseñador de Interfaces
Principios que sustentan la
metodología- EL Personal: Gestión de
Proyecto - El Problema: Gestión del
Cliente - El Proceso: Ciclo de Vida de
Desarrollo
Ciclo de vida de desarrollo
- Definición del problema.
- Identificación de los procesos
unitarios. - Diseño del prototipo.
- Desarrollo del prototipo.
- Prueba del prototipo.
- Si <no prueba de Prototipo>ir a Paso
3. - Si <Prototipo difiere Sistema Deseado>ir a
Paso 2. - Si <no Necesidades satisfechas>ir a Paso
2. - Implantación.
- Mantenimiento.
Resumen puntos clave
RUP
- Pesado
- Dividido en cuatro fases, que se dividen en
iteraciones - El discurrir del proyecto se define en
Workflows - Los artefactos son el objetivo de cada
actividad - Se basa en roles
- UML
- Muy organizativo
- Mucha documentación
3P
- Ágil
- Cercano al desarrollo, pero sin olvidar el
diseño. - Se basa en 3 principios:
Personal, Problema, Proceso. - Gran interacción con el
cliente. - Pruebas de funcionalidad y calidad.
- Logra alcanzar un control
y organización del proceso. - Logra un equilibrio en cuanto a la generación
de documentación
XP
- Ligero
- Cercano al desarrollo
- Se basa en UserStories
- Fuerte comunicación con el
cliente - El código fuente pertenece a
todos - Programación por parejas
- Tests como base de la funcionalidad
- Solo el mínimo de
organización - Pobre en cuanto a
documentación
3.
Conclusiones¿Qué debemos esperar entonces de un
proceso de desarrollo?¿Qué criterios debe cumplir para que
aporte algo a la
empresa?Básicamente el proceso de desarrollo tiene
que ayudarnos a escribir software, tiene que poner las reglas
necesarias para alcanzar el éxito en nuestro proyecto
pero dejando la libertad
suficiente para no sentirnos agobiados.Esto no nos lo va a ofrecer ningún proceso
estándar, y como dice el refrán (aunque no se
cumple exactamente en el mundo de la informática) todos los caminos
conducen a Roma.De forma que es tarea de cada empresa, casi
para cada proyecto, decidir cual es el mejor modo de llegar a
nuestra meta.Referencias
- [ANO08,1]. Anónimo. Seminario sobre RUP
en un entorno empresarial de desarrollo.
http://www-5.ibm.com/services/learning/es/tairis.nsf/(ExtCourseNr)/RUPS1ES.
(2/5/08) - [ANO08,2]. Anónimo. Rational Unified
Process. .
(2/5/08) - [ANO05,3]. Anónimo. Proceso Unificado
de Rational para el desarrollo de software.
http://www.dybox.cl/metodologia/rup.html.
(2/5/08) - [BAR08]. Barrientos Enríquez, Aleida
Mirian. El desarrollo de sistemas de
información empleando el lenguaje de modelado
unificado UML. - [JAC08]. Jacobson, Ivar; Booch, Grady; Rumbaugh,
James. El Proceso Unificado de Desarrollo de
Software. - [ECH08]. Echevarría Cossío,
Yanelis. Modelo Ágil de Desarrollo de Proyectos
de Software:Paradigma 3P.
Bibliografía
- Alianza Ágil, http://www.agilealliance.org
- Patricio Letelier, Departamento de Sistemas
Informáticos y Computación, Universidad Politécnica de Valencia,
letelier[arroba]dsic.upv.es - Manifiesto para el Desarrollo de Software
Ágil, http://www.agilemanifesto.org - Martín Fowler, La Nueva
Metodología, http://www.programacion.net - Alistair, Desarrollo de Software
Ágil,
http://www.amazon.com/exec/obidos/ASIN/0201699699/programacione-20- Jacobson, Ivar; Booch, Grady; Rumbaugh, James.
El Proceso Unificado de Desarrollo de
Software. - Echevarría Cossío, Yanelis.
Modelo Ágil de Desarrollo de Proyectos de
Software:Paradigma 3P. - Anónimo. Proceso Unificado de Rational
para el desarrollo de software. - http://www.dybox.cl/metodologia/rup.html.
(2/5/05) - Anónimo. Rational Unified
Process.
http://www.itera.com.mx/itera/productos/fundamentos.asp.
(2/5/05) - Anónimo. Seminario sobre RUP en un
entorno empresarial de desarrollo.
http://www-5.ibm.com/services/learning/es/tairis.nsf/(ExtCourseNr)/RUPS1ES.
(2/5/05) - Barrientos Enríquez, Aleida Mirian. El
desarrollo de sistemas de información empleando el
lenguaje de modelado unificado UML.
Autor:
Erly Delgado Expósito
 Página anterior | Volver al principio del trabajo | Página siguiente  |